For realizing virtual private networks in the Internet, the so called VPN technology has been developed. A virtual private network (VPN) is a private communications network usually used within a company, or by several different companies or organizations, to communicate over a public network. VPN message traffic is carried on public networking infrastructure (e.g. the Internet) using standard (often insecure) protocols, or over a service provider's network providing VPN service guarded by well-defined Service Level Agreement (SLA) between the VPN customer and the VPN service provider.
VPN involves two parts: the protected or “inside” network that provides physical security and administrative security sufficing to protect transmission (sometimes it is not always the case), and a less trustworthy or “outside” network or segment (the Internet). Generally, a firewall sits between a remote user's workstation or client and the host network or server. As the user's client establishes the communication with the firewall, the client may pass authentication data to an authentication service inside the perimeter. A known trusted person, sometimes only when using trusted devices, can be provided with appropriate security privileges to access resources not available to general users.
Many VPN client programs can be configured to require that all IP traffic must pass through a “tunnel” while the VPN is active, for better security. From the user's perspective, this means that while the VPN client is active, all access outside their employer's secure network must pass through the same firewall as would be the case while physically connected to the office Ethernet. This reduces the risk that an attacker might gain access to the secured network by attacking the employee's laptop: to other computers on the employee's home network, or on the public internet, it is as though the machine running the VPN client simply does not exist. Such security is important because other computers local to the network on which the client computer is operating may be untrusted or partially trusted. Even with a home network that is protected from the outside internet by a firewall, people who share a home may be simultaneously working for different employers over their respective VPN connections from the shared home network. Each employer would therefore want to ensure their proprietary data is kept secure, even if another computer in the local network gets infected with malware. And if a travelling employee uses a VPN client from a WiFi access point in a public place, such security is even more important. However, the use of IPX/SPX is one way users might still be able to access local resources.
Tunneling is the transmission of data intended for use only within a private, usually corporate network through a public network in such a way that the routing nodes in the public network are unaware that the transmission is part of a private network. Tunneling is generally done by encapsulating the private network data and protocol information within the public network transmission units so that the private network protocol information appears to the public network as data. Tunneling allows the use of the Internet, which is a public network, to convey data on behalf of a private network.
Within the Internet Engineering Task Force (IETF) there are some working groups involved in adding Quality of Service (QoS) enhancements to the VPN technology. The Integrated Services (IntServ) working group has discussed some tunneling as well as aggregation mechanisms. They are described in the Request for Comments documents RFC2379, RFC2746, RFC2998 and RFC3175.
Speaking about Traffic Engineering and QoS, the Multiprotocol Label Switching (MPLS) networking technology is of great interest. This technology comes with sophisticated Traffic Engineering and QoS support. Also it uses tunneling and fits well to the VPN technology. A dedicated signaling extension to perform Traffic Engineering within MPLS networks has been specified as well [see RFC3209, RFC3630, RFC3107, RFC3212]. Especially operation of Resource Reservation Protocol (RSVP)-controlled IP connections over Differentiated Services (DiffServ) networks and the mapping of these data flows to an appropriate DiffServ codepoint (DSCP) have been described within corresponding documents of the IETF [see RFC2998, RFC3175].
The main disadvantages of those approaches discussed within the IETF are the following:
At least parts of the networks, both at the sending and receiving side, have to be RSVP-aware. RSVP tunneling mechanisms only handle the transmission across an inner part of an IP network—see FIG. 1.
In FIG. 1 reference 10 denotes the Internet. With reference 20 RSVP domains inside the Internet are denoted. Inside the left RSVP domain 20 a sending station 21 is depicted. Inside the right RSVP domain 20 a corresponding receiving station 23 is depicted. The two RSVP domains 20 may be located in different areas in the world. One domain might be in CA USA, whereas the other domain is in Europe, e.g. in England. Both domains belong to two trusts worthy places of an organization or company. For a QoS assurance along the patch, the technique of RSVP tunneling is used. The established tunnel has been labeled with reference number 40 in FIG. 1.
Especially if the sender and receiver reside in different administrative domains and VPN technologies like MPLS are applied to the inner network, the receiver side will often not be required to be RSVP-capable, as the inner network will typically already provide some QoS control, like overprovisioning or statically configured priority queuing mechanisms on behalf of the receiver side according to the QoS capabilities of the receiver side.
RSVP advertises a fine-grained traffic (flow) description, network resources should be reserved for, but network operators are commonly unable to handle a large amount of reservations on such a fine-grained basis or map such fine defined requests to classes of services, appropriately.
Although flow aggregation is considered in RFC2746 and RFC3175, the aggregation model described in those documents is only applicable to RSVP-aware networks.
With the common IntServ/RSVP model, IP connectivity between the sender 21 and the receiver 23 must be existent at the resource reservation time. Only establishment of tunnels using aggregated RSVP, maybe in combination with DiffServ, within an IP network on behalf of an RSVP reservation request is specified within the IETF documents.